Modelo de implementación de Seguridad

El presente documento detalla la implementación de seguridad sólo a nivel de la aplicación, en base a los conceptos partidos de los anteriores modelos de seguridad y menú, así como la especificación del DER propio dentro de la base de datos para tratar estos tópicos, vinculados a los servicios de la base de directorio. Aunque esta documentación estipula específicamente las especificaciones sobre la aplicación, inevitablemente debemos hacer referencia al manejo de usuarios del dominio Windows implementado en Samba ya que los usuarios en el directorio son los autoritativos. Por ello comenzaremos por este lado y luego seguiremos con la implementación propia referente a la aplicación.

1 - ABM de usuarios en el dominio, datos propios de los usuarios internos

Los usuarios internos son todo el personal de la Obra Social. En el momento de la incorporación de un empleado (cualquiera sea su cargo), el administrador del dominio deberá darlo de alta como tal bajo el contenedor correspondiente (en Casa Central o en alguno de los CAP). Esto lo debe hacer a través de alguna de las herramientas administrativas que provee Samba como WEBMIN o SWAT, que son aplicaciones WEB de uso libre, o con las propias herramientas de samba por línea de comando, como el smbpasswd.

La estructura corporativa del árbol será como se muestra a continucación:

donde Sede Central es el contenedor que representa la Casa Matriz de la Obra Social y CAPn es el contenedor que representa a cada CAP. A la altura de los contenedores deberá crearse el usuario administrador general de todo el directorio, con derechos de supervisor sobre roto el árbol (desde o=Miklolife hacia abajo en el subárbol, heredando los permisos hacia abajo).

Los usuarios entrantes deberán incorporarse debajo del contenedor donde estén trabajando físicamente, posibilitando el moviemiento a otro contenedor en caso de viaje o cambio de lugar físico de trabajo. Adicionalmente se genera un contenedor ou=Grupo_Gestion exclusivo para la nuestra aplicación, debajo del cual estáran los grupos representativos de roles dentro de la aplicación, tema que se tratará en breve y con sumo detalle. El contenedor ou=Desafectados es para uso exclusivos de usuarios desafectados de la empresa. Finalmente, en el contenedor ou=Extranet deberán ubicarse los afiliados, que no son usuarios internos, sólo a los efectos de autenticación. Este tópico también será discutido en breve.

El administrador deberá setear un password default que el usuario deberá cambiar la primera vez que se loguée al dominio desde una de las terminales (es importante destacar que el administrador del dominio debe incorporar los trustees corresponspondientes para todas las máquinas dentro de la organización). Este procedimiento fue descrito en el modelo 13, conceptos de seguridad, en donde se detalla las precauciones a tomar en el intermedio en que se pise un password de usuario o se cree uno por primera vez.

Las políticas de password establecidas son de 6 caracteres mínimo, incluyendo por lo menos un caracter numérico. Se establecerá adicionalmente una política de caducidad de contraseña de 60 días, impidiendo establecer la contraseña actual como próxima en el momento de cambio.

Para la desafectación de usuarios se tomará la siguiente política: cuando un empleado es despedido o se desvincula por otro medio de la empresa, se lockea su cuenta vía LDAP y se mueve el mismo al contenedor ou=desafectados. A los 30 días el usuario es borrado definitivamente del directorio.

2 – ABM de usuarios externos, usuario administrativo para la aplicación

La aplicación deberá contar con un usuario administrativo para realizar las tareas de autenticación, autorización y creación de usuarios externos. Este usuario estará dentro del contenedor de la Casa Central y se su DN (Distinguished Name) será cn=admin_gestion,ou=Sede_Central,o=Miklolife. El mismo deberá tener los siguientes permisos:

Sobre los contenedores de usuarios (todos estos permisos heredados al subárbol):
Búsqueda
Comparación de atributos
Lectura de objetos y sus atributos

Sobre el contenedor ou=Grupo_Gestion,o=Miklolife deberá tener (todos estos permisos heredados al subárbol):
Búsqueda
Comparación de atributos
Lectura de objetos y sus atributos
Creación
Modificación de atributos
Renombrado
Eliminación

A su vez, y como se ve en la figura esquemática del directorio, habrá un contenedor externos. Dentro del mismo se alojarán los usuarios que no son empleados de la corporación, es decir aquellos que realicen tareas desde los prestadores y los pacientes mismos. El Distinguished Name del contenedor será ou=Externos,o=Miklolife y tendrá los siguientes permisos (todos heredados al subárbol):

Búsqueda
Comparación de atributos
Lectura de objetos y sus atributos
Creación
Modificación de atributos
Renombrado
Eliminación

Estos usuarios tendrán pocos atributos habilitados como se veerá luego, y servirán para loguearse remotamente hacia la aplicación, pero usando el mismo repositorio de identidades que el resto de los usuarios de la aplicación. Los mismos basarán su comportamiento bajo el mismo esquema que el resto, por asignación a grupos dentro del contenedor de grupos, que será quien defina el o los perfiles de los usuarios.

3 – Datos propios de los usuarios, contenedores y grupos

Como se especificó anteriormente, se emplearán las RFC 3377, 2251, 2252, 2253, 2254, 2256, 2829-2830, y particularmente para los usuarios, la RFC 2798 que define la clase estructural inetOrgPerson y la RFC 2307 que define las clases posixAccount, posixGroup, shadowAccount auxiliares utilizadas por Samba, así como también las clases propias de Samba como sambaSamAccount. También se utilizarán las clases estructurales organization y organizationalUnit para los respectivos contenedores que jerarquizan al árbol, y la clase estructural groupOfUniqueNames para los grupos.

A continuación se detallan los atributos que tendrán las entries de cada clase, exceptuando a los usuarios que se tratarán luego con más detalle:

Organización: es la raíz del subárbol que representa la corporación, serán instancias de la clase organization. Solamente contendrá su DN, el atributo O con el RDN del objeto, y una descripción, en la misma se presentará la razón social de la empresa.

Contenedores: serán de la clase organizationalUnit. Dividen jerárquicamente al árbol para no hacerlo plano si no corporativo, conteniendo a los distintos usuarios y grupos de manera separada según ubicaciones físicas y roles. Serán cargados su DN, el atributo ou que forma su RDN y como descripción deberán contener el motivo por el cual se realizó dicha subdivisión lógica.

Grupos: serán de la clase groupOfUniqueNames definida en X.500, y adicionalmente tendrán la clase auxiliar posixGroup para el tratamiento Samba, en el cual no ahondaremos. Estos objetos tendrán cargado su DN, el CN como RDN del mismo, y los atributos optativos description, donde estará el papel que juega el grupo en la corporación o a nivel de aplicación,  y uniqueMember, que contendra el DN de los usuarios que pertenezcan a este grupo. Los atributos cargados por Samba no serán descriptos en este documento, y están disponibles online en www.samba.org, lo mismo para los usuarios.

Usuarios Internos

Este tipo de objeto será tratado especialmente y se mostrarán los datos necesarios para los usuarios empleados de la organización. A continuación se muestra una tabla con los atributos de la clase inetOrgPerson que serán utilizados (no serán utilizados todos), y un mapeo al mundo humano de que representa cada atributo. Los atributos están definidos en esta clase y en las clases de la que hereda (organizationalPerson, person, Top)  según la RFC 2798:

Nombre del atributo	Nombre descriptivo	
uid	Apodo del usuario	
cn	Apodo del usuario	
sn	Apellido	
givenName	Primer Nombre	
fullName	Nombre Completo	
departmentNumber	Numero de CAP / Sede Central	
employeeNumber	Número de legajo	
employeeType	Tipo de empleado (efectivo, pasante, contratista)	
homePhone	Teléfono Particular	
homePostalAddress	Dirección Particular	
mail	Mail corporativo	
photo	URI a la foto del empleado	
userPassword	Password del usuario, encriptado según el directorio elegido (este atributo no se puede leer como parte del esquema, sólo admite un compare, esto es a nivel estándar X.500)	
description	Observaciones Generales	
title	Cargo del Empleado	
ou	Area	
L	Zona de trabajo	

Usuarios Externos

A continuación se presenta la misma tabla con los atributos necesarios (y únicos) para los usuarios externos como prestadores y afiliados:

Nombre del atributo	Nombre descriptivo	
uid	Apodo del usuario	
cn	Apodo del usuario	
sn	Apellido	
givenName	PrimerNombre	
fullName	NombreCompleto	
homePhone	Teléfono Particular	
homePostalAddress	Dirección Particular	
mail	Mail corporativo	
userPassword	Password del usuario, encriptado según el directorio elegido (este atributo no se puede leer como parte del esquema, sólo admite un compare, esto es a nivel estándar X.500)	

4 – Programas a utilizar

Ya hemos establecido que el dominio será windows pero administrado desde un SAMBA, aplicación de uso gratuito disponible en internet. Para soporte de ésta aplicación distribuída, se utilizará un sistema operativo Novell Suse Enterprise 9 (no Netware) que correrá bajo las especificaciones planteadas en el modelo 13, conteptos de seguridad. El mismo sistema operativo será utilizado para soportar al directorio. Para la base del directorio hay una amplia gama de opciones, como por ejemplo:

•	eDirectory, de Novell
•	Active Directory, de Microsoft
•	Oracle Internet Directory, de Oracle
•	OpenLDAP, del grupo OpenLDAP y de distribución gratuita

AD y OID de Microsoft y Oracle respectivamente los descartamos de inmediato por sus bajas prestaciones y difícil administración. La elección se inclina hacia Novell eDirectory, producto de muchos años de antigüedad y totalmente robusto. El mismo utiliza MD5 para proteger internamente sus datos haciéndolo difícil de vulnerar. OpenLDAP se descartó a pesar de ser una opción OpenSource, ya que es pésimo a nivel de directorio, si bien cumple con todos los estándares, posee muchas limitaciones y características que el mismo grupo OpenLDAP piensa no desarrollar en el futuro.

Para las estaciones de trabajo, se instalará un windows 2000 professional, y la aplicación de gestión. Se limitará la manejabilidad del sistema operativo por parte del usuario comun, y se activará un protector de pantalla con contraseña a los 5 minutos de desuso, de modo tal que la estación permanezca lockeada en caso de que el usuario deje su puesto de trabajo momentáneamente.

En cuanto al motor de base de datos a utilizar existen varias alternativas también:

•	SQL Server 200X de MS
•	Oracle 10
•	Mysql
•	PostgreSQL

La inclinación surge hacia PostreSQL debido al alto contenido de prestaciones y características embebidas y a que es de uso gratuito, compitiendo con Oracle, cuyo motor es muy potenten y sus prestaciones son altas, como tambíen la de SQL Server. MySQL todavía está carente de ciertas características que facilitan el desarrollo, rasón por la cual queda en último lugar entre los motores posibles.

5 – Base de Datos Relacional, diseño y características

Como se explicó en el modelo 13, conceptos de seguridad, para manejarla a nivel aplicación se combina la potencia del directorio con tablas paramétricas de la base de datos propia de la aplicación. A nivel esquemático, se mostrará nuevamente la figura del modelo anterior:

Los grupos del directorio (clase groupOfUniqueNames) serán quienes llevarán la tarea de mantener el perfil del usuario. Un usuario puede pertenecer a todos los grupos que desee, de manera que se pueden combinar haciendo perfiles más complejos. Para ver los perfiles por defecto que deberán estar inicialmente, ver la sección 6.

Recaerá luego en la base de datos relacional el parametrizar cada grupo contra una funcionalidad propia de la aplicación. A continuación se detalla el DER de esta porción de la base de datos de la aplicación, completamente aislada e independiente del resto de las tablas y relaciones:

Explicaremos a continuación el significado y uso de cada una de las tablas.

Diccionario de datos

Tablas

Tabla	Descripción	
Perfil_Funcionalidad	Su objetivo es mapear un grupo del directorio contra una funcionalidad propia de la aplicación.	
Funcionalidad	Tabla paramétrica que contiene todas las funcionalidades posibles dentro de la aplicación.	
Funcionalidad_Menu	Desglosa cada funcionalidad en subactividades, y serán las que utiliza la aplicación para mostrar en pantalla.	

Diccionario de composición de los campos

Tabla	Campo	Tipo	Nulo	PK	FK	Referencia	
Perfil_Funcionalidad	Id	Integer	NO	SI	NO		
	Nombre_grupo	Varchar	NO	NO	NO		
	Fid_funcionalidad	Integer	NO	NO	SI	Funcionalidad	
Funcionalidad	Id	Integer	NO	SI	NO		
	Nombre_funcionalidad	Varchar	NO	NO	NO		
	Descripcion	Varchar	SI	NO	NO		
Funcionalidad_Menu	Id	Integer	NO	SI	NO		
	Fid_funcionalidad	Integer	NO	NO	SI	Funcionalidad	
	Nombre_Menu	Varchar	NO	NO	NO		
	Descripcion_menu	Varchar	SI	NO	NO		

Especificación descriptiva de los atributos

En primer lugar, tenemos la tabla Perfil_Funcionalidad. Dentro de ésta tabla tenemos un id interno a la tabla de modo de poder identificar como único a cada registro. Luego tenemos nombre_grupo, que es el nombre textual de uno de los grupos mantenidos en el contenedor de grupos del directorio (debe coincidir con el atributo CN del mismo). Finalmente, tenemos fid_funcionalidad que es la clave foránea hacia una funcionalidad, dentro de la entidad Funcionalidad que será descrita en el próximo paso.

En la tabla Funcionalidad, tenemos un id identificador único de cada registro y clave primaria de la tabla. Luego vemos el campo nombre_funcionalidad, que deberá ser un nombre corto distinsor de una de las funcionalidades de la aplicación. Finalmente, el atributo descripción, que explayará brevemente el uso de tal funcionalidad. Esta es una tabla netamente paramétrica.

Por último, contamos con la tabla Funcionalidad_Menu, cuya función es el desglose de cada funcionalidad en diferentes subactividades. Cada una de éstas será un ítem de menú, tal como se explicó en el modelo 12, diseño conceptual de menú. Como siempre, el campo id identifica lógicamente a cada registro. Luego, fid_funcionalidad será un foráneo hacia una funcionalidad de la tabla del párrafo anterior. Luego vemos a nombre_menu que es un descriptivo corto de la actividad que proporcionará el item en cuestión y es lo que se mostrará en pantalla, y descripcion_menu es una breve descripción hacerca de que realiza esta subactividad desprendida de cierta funcionalidad.

Reglas de Integridad Referencial

Tabla Funcionalidad:

Al borrarse un registro de esta tabla, deben borrarse en cascada aquellos que le hacían referencia desde las tablas Perfil_Funcionalidad y Funcionalidad_Menu. Esta operación es muy crítica, ya que se está sacando una funcionalidad completa a la aplicación.

Cuando se da de alta, no es necesario en principio que Se generen registros en las otras dos tablas. Si no contiene registros referenciados en Funcionalidad_Menu, simplemente se toma como que dicha funcionalidad no posee subactividades.

Tabla Perfil_Funcionalidad:

Tanto al crear o borrar un registro, el mismo no tiene impacto en el resto de las tablas. Simplemente se le está agregando o sacando respectivamente, una funcionalidad al rol elegido.

Tabla Funcionalidad_Menu:

En este caso la creación y el borrado son irrestrictos como en el caso anterior. Crear o borrar un registro implica agregar o eliminar una subactividad a una funcionalidad.

6 – Perfiles y funcionalidades por defecto

En el momento inicial la aplicación contará con ciertos perfiles ya creados por defecto. Los mismos estarán contenidos dentro del contenedor ou=Grupo_Gestion,o=Miklolife y serán los siguientes grupos:

RDN (Relative Distinguished Name)	Objetivo	
Cn=autenticados	Representa a todos los usuarios que tienen acceso a la aplicación. Solamente los usuarios que se encuentren dentro de este grupo podrán intentar autenticarse contra la aplicación, de lo contrario serpán rechazados automáticamente.	
Cn=Administradores	Representa a los usuarios cuyo rol es Administrativo (ver el actor Administrador en el caso de usos).	
Cn=Prestadores	Representa a los usuarios que son empleados de las  prestadoras, los mismos estarán en el contenedor ou=Extranet,o=Miklolife y tendrán todas aquellas funcionalidades habilitadas para usuarios empleados de las distintas prestadoras de la Obra Social.	
Cn=Afiliados	Representa a los usuraos afiliados a la obra social, que accederan por medio de la extranet para realizar tareas sobre sus cuentas y a nivel general acerca de su Plan. Estos usuarios estarán contenidos dentro de ou=Extranet,o=Miklolife.	
Cn=Operadores	Representa a todos los usuarios cuyo rol es Operador (ver el actor del mismo nombre en el caso de uso).	

Así mismo, y relacionadas con los grupos anteriores, se deberán presentar las siguientes funcionalidades por default:
Grupo (perfil)	Funcionalidad	
Cn=Administradores	•	ABM de usuarios
•	ABM de funcionalidades
•	ABM de planes
•	ABM de prestaciones
•	ABM de afiliados
•	ABM de promotores
•	Generación de reportes
•	ABM de perfiles (Grupos)	
Cn=Prestadores	•	Recibir y Cotejar consumos y Prestaciones	
Cn=Operadores	•	Atender Consulta Afiliado
•	Armar Cartilla
•	Ingresar Solicitud
•	Agregar Afiliado
•	Pedir Autorización Manual	

7 – Operatoria diaria – Integración del directorio y la base de datos

En esta sección se mostrarán las actividades relacionadas a seguridad por parte de la aplicación y se delineará con detalle cómo se debe proceder para implementar tales actividades.

7.1 – Login en el Dominio

Este tópico no hace a la aplicación y se describirá brevemente el sistema de login de un dominio windows, aunque no se graficará ni entrará en detalles con respecto al mismo.

El usuario introduce su usuario y password así como también especifica el dominio al que se quiere loguear. En ese momento, la máquina envía al PDC una petición de login, junto con el modo de encriptación utilizado (NT o LanManager, ver el glosario del modelo 13). El PDC contesta (si la máquina está registrada) con un string de 8 bytes random, llamado challenge. El mismo llega a la máquina. Allí se encripta NT o LanManager el password introducido por el usuario, y con él encripta el challenge y se envía el resultado al PDC. Del otro lado, el PDC hace lo mismo con el password que tenía almacenado para el usuario (lo busca del objeto usuario del directorio) y finalmente compara estos dos strings, autenticando la veracidad del usuario si el resultado de la comparación es positivo, o denegándo su acceso al dominio si es negativo.

7.2 – Login a la aplicación

Este proceso se relatará en detalle ya que se considera crucial en cuanto al tema de seguridad. Una vez adentro de la aplicación, el usuario podrá hacer todo lo que su rol le permita con lo cual una vulneración en esta parte puede llegar a romper el negocio.

La pantallad de login es simple y consta de dos cajas de texto, una para ingresar un username y luego un password, éste último mostrando como echo caracteres asterisco.

La autenticación constará de los siguientes pasos:

1.	El usuario ingresa su username y su password. El usuario uid=admin_gestion,ou=Sede_Central,o=Miklolife en el cual se impersonifica la aplicación, realiza una conexión contra el server LDAP, y un bind con sus credenciales propias, hardcodeadas en la aplicación (bind es el término por el cual se toma las riendas de las operaciones del directorio bajo cierto usuario, seteándose automáticamente los permisos correspondientes). El siguiente paso es hacer un searh LDAP, a partir de o=Miklolife, con scope subtree (ver la RFC 2254 para los detalles de la búsqueda y los filtros LDAP). Se usará el siguiente filtro (&(objectclass=inetOrgPerson)(uid=XXXXX)). Este filtro, para el público sql, es un análogo a la porción where en un select sql. El mismo está en notación prefija, y lo que queremos precisar acá es que el server devuelva aquellos objetos (debería ser uno sólo o ninguno) con clase inetOrgPerson (es un usuario) y cuyo uid es XXXXX (donde esto último es el username introducido por el usuario). Si el mismo no existe en el directorio (código LDAP 32 – No Such Entry), la autenticación falla y se deniega el acceso al usuario. Si el usuario existe, se pasa al punto 2 (código LDAP 0, success). Si hubiere más de un resultado, se deniega el acceso, pero este es un error administrativo, ya que no deberían haber dos usuarios iguales ya que esto está restringido por el dominio.
2.	En este punto obtenemos el DN del usuario resultante de la búsqueda del punto 1. Ahora, se realiza un bind LDAP con este mismo usuario (con su DN y su password), esta acción se traduce como un rebind. Si la misma falla (código LDAP 49, Invalid Credentials), el password ingresado por el usuario es incorrecto y se deniega el acceso. Si el código es 0 – Success el usuario está casi adentro de la aplicación y se pasa al punto 3.
3.	El siguiente paso es buscar si el usuario está en el grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife. Si no se encuentra dentro del mismo (atributo uniqueMember) se deniega el acceso al mismo (el usuario es parte del dominio pero no de la aplicación). Si el DN del usuario se encuentra entre los miembros del grupo, entonces el usuario pertenece a la aplicación y está adentro de la misma.

Es importante destacar que en cada punto se posibilita una denegación de ingreso al usuario por alguna causa. Bajo ningún concepto hay que darle al usuario información del por qué de la falla de la autenticación ya que estas son pistas que pueden ayudar a piratas informáticos. Ante cualquier error, se devolverá el mensaje “Su usuario o password son incorrectos”. Es el único mensaje que se arrojará ante un login erróneo.

El paso siguiente es realizar la autorización del usuario. Para ello, se buscan aquellos grupos en cuyo atributo uniqueMember figure el DN del usuario logueado. Luego, con la lista de estos grupos, se entra en la base de datos en la tabla  Perfil_Funcionalidad, y se buscan todas las entradas de la tabla que tengan los grupos resultantes de esta última búsqueda. Una vez detectadas estos registros, se tendrán las funcionalidades asociadas al rol del usuario dentro de la tabla Funcionalidad y junto con ellas, los ítems de menú cuando correspondan, si es que hay asociados registros en la tabla Funcionalidad_Menu.

El siguiente esquema representa el usuario en la autenticación y búsqueda de perfiles para mantener una mejor idea conceptual de lo que se pretende lograr.

7.3 – ABM de usuarios internos

Para estos procesos se deberá utilizar un usuario perteneciente al grupo cn=Administradores,ou=Grupos_Gestion,o=Miklolife.

Alta

Para dar de alta un usuario, se ingresará el username del mismo, y con éste se hará una búsqueda en todo el árbol, a partir de o=Miklolife. Si el usuario no existe, se informa del hecho y se deniega el alta del mismo (un usuario debe pertenecer a la corporación).

En caso de existir el usuario, simplemente se lo agrega (controlando que no estuviera previamente incluído) al grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife.

El siguiente paso es asignarlo a los perfiles correspondientes, con lo cual el paso siguiente es traer todos los grupos (menos cn=autenticados) debajo del contenedor ou=Grupo_Gestion,o=Miklolife. Se mostrará una lista de los mismos (solamente el valor del atributo CN). El usuario administrador podrá asignarlo a múltiples perfiles, desde un combo multiseleccionable desplegable. Finalmente, se asignará el usuario a cada uno de los grupos elegidos vía LDAP. Un usuario puede ser ingresado sin membresías previas, simplemente no se le presentará ninguna actividad al loguearse a la aplicación. Luego podrán agregarse membresías en la instancia de modificación.

Modificación

Para los usuarios internos a la corporación, no se permitirán modificar datos inherentes al mismo dentro de esta aplicación, debe realizarse desde alguna de las herramientas administradoras del dominio. En esta instancia para estos usuarios, se permitirá cambiar las membresías a los grupos que harán el perfil del usuario. Para ello se presentará un combo como en el proceso de alta, con los grupos actuales a los que el usuario está inculado preseleccionados. Se elegirán los que se desee para el usuario en cuestión, y se guardarán sus membresías vía LDAP.

Baja

La baja de un usuario simplemente consiste en desvincularlo de todos los grupos dentro del contenedor ou=Grupos_Gestion,o=Miklolife. En realidad basta con sacarlo del grupo cn=autenticados pero se le sacará la membresía a todos los grupos de modo de no dejar basura.

7.4 – ABM de usuarios externos

Para estos procesos se necesitará un usuario que sea miembro del grupo cn=Administradores,ou=Grupos_Gestion,o=Miklolife. Todos los usuarios tratados estarán únicamente en el contenedor ou=Extranet,o=Miklolife.

Alta

El alta de usuarios externos es similar a la de los internos pero se le permitirá además llenar los campos Username (uid y cn) ,Apellido (sn), Primer Nombre (givenName), Nombre Completo (fullName), Teléfono (homePhone), Dirección (homePostalAddress), mail (mail) y password (userPassword), con retipeo de este último, y ocultando los caracteres presentando asteriscos en la pantalla (entre paréntesis se muestran los atributos que se guardarán a nivel LDAP). Sólo el campo Apellido será obligatorio, ya que con él se guarda el campo sn del objeto usuario y en la clase estructural inetOrgPerson este atributo es mandatario. Se deberán parsear los campos ingresados para evitar errores o intentos malintencionados de guardar información (igualmente cada atributo del directorio tiene su propia sintaxis y no admitirá valores que se alejen de la misma). En cuanto a los passwords, el directorio propio controlará según las políticas establecidas. 
Adicionalmente se presentará un grupo de radio buttons con las leyendas Prestador y Afiliado, cada uno con un radio asociado.

Antes de guardar el nuevo objeto usuario, se mostrará una pantalla preview con los datos ingresados (menos el password) y se pedirá confirmación o modificación de los datos, volviendo al paso anterior. Los campos en caso de modificación deberán ser prellenados con los valores entrados en el paso anterior.

Una vez con todos los datos del usuario, se procede a crear un objeto usuario, impersonificándose en el usuario cn=admin_gestion,ou=Sede_Central,o=Miklolife. El usuario se creará en el contenedor ou=Externos,o=Miklolife, y se asignará al grupo cn=Prestadores,ou=Grupo_Gestion,o=Miklolife, o a cn=Afiliados,ou=Grupo_Gestion,o=Miklolife según se corresponda a un usuario de las prestadoras o a un afiliado de la Obra Social. Adicionalmente se deberá agregar a cn=autenticados,ou=Grupo_Gestion,o=Miklolife, que como es de saber, corresponde a los usuarios de esta aplicación.

Si la respuesta es 0 – Success se dara por finalizada la alta. Si la respuesta es distinta, como un 68 - entry already exists, 65 – object class violation, etc, se deberá volver al paso anterior y modificar los datos. No puede haber usuarios con el mismo username dentro de un mismo contenedor.

Modificación

En esta etapa, se selecciona un usuario ya existente, y se permitirá modificar todos los campos (menos el password) del usuario. Este esquema es exactamente idéntico al alta, con la salvedad de que los campos serán prellenados. El cambio de password será tratado aparte.

En el caso de estos usuarios, por ser externos, la modificación no contemplará cambios en las membresías ya que las funcionalidades serán las del grupo al que pertenecen.

Como en el alta, antes de guardar las modificaciones se presentará una pantalla a modo de preview con los datos ingresados, y un botón para confirmar junto a otro para volver atrás.

Luego, se procede a hacer un ldap modify y como siempre, chequear que la respuesta del server sea exitosa, o en caso contrario volver a la pantalla inicial.

Baja

Simplemente se los saca del grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife, y del grupo correspondiente si bien es un usuario de un prestador o un usuario afiliado de la Obra Social.

7.5 – Cambios de Password

Usuarios Internos

No se les permitirá el cambio de password. Todos los usuarios que no pertenezcan a los grupos cn=Prestadores,ou=Grupo_Gestion,o=Miklolife o cn=Afiliados,ou=Grupo_Gestion,o=Miklolife deberán modificar sus password por medio de la terminal utilizando las técnicas conocidas de windows (ctrl+alt+del y luego Change Password). Esto cambiará el password del dominio, modificando también los passords LanManager / NT, con lo cual el usuario tendrá su nueva credencial para loguearse a todas las aplicaciones que utilicen al directorio como repositorio central de identidades.

Usuarios Externos

A los usuarios prestadores y afiliados se les permitirá cambiar su password en un módulo aparte. Todos los usuarios pertenecientes a estos grupos deben tener una funcionalidad de cambio de password y lo podrán hacer por las suyas. El mismo es cambiado a nivel LDAP y el atributo modificado es userPassword. El directorio tendrá una política establecida de modo que no se pueda volver a poner el password anterior como vigente.

En este módulo simplemente se mostraran dos cajas de texto, y el usuario deberá rellenarlas con lo nuevos passwords, por duplicado para corroborar que no haya habido errores de tipeo. Paso seguido se impersonifica en el usuario propio, y se modifica su password vía  LDAP, controlando que el server LDAP retorne siempre un 0 – Success y de lo contrario volver al paso anterior.

7.6 – Salida de la aplicación

Este evento no tiene ninguna actividad a nivel de directorio. Simplemente la aplicación vuelve a la pantalla de login pidiendo nuevas credenciales para tener acceso a la aplicación. De esta manera, el usuario no tiene acceso a ningún módulo si no se loguea a la aplicación (se vuelve al punto 7.2).

7.7 – Ver usuarios

En este módulo, se presentará una lista seleccionable simple con todos los usuarios debajo de o=Miklolife que pertenezcan al grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife. Una vez elegido el usuario, se mostrarán todos los atributos relevantes del mismo (sólo los que tiene cargados en el entry del directorio), y las membresías a las cuales pertenece (en el caso de externos, se mostrará si es prestador o afiliado).

7.8 – ABM de perfiles

En este apartado, se trata el agregado de nuevos perfiles a la aplicación. En este caso se debe acceder a la base relacional además del directorio jerárquico. Para estas operaciones la aplicación se debe impersonificar en el usuario cn=admin_gestion,ou=Sede_Central,o=Miklolife.

Alta

En el alta, se pedirá el nombre del nuevo perfil y se mostrará una lista de las funcionalidades existentes. El usuario administrador deberá seleccionar del combo múltiple aquellas funcionalidades que desea tenga el nuevo perfil. Previo a una pantalla de previsualización, se procederá a los siguientes dos pasos:

1.	Crear un nuevo grupo, dentro del contenedor ou=Grupo_Gestion,o=Miklolife con cn=XXXX donde XXXX es el nombre del nuevo perfil.
2.	En la tabla Perfil_Funcionalidad, se agrega por cada funcionalidad elegida, un nuevo par nombre_grupo / fid_funcionalidad (Ver der anterior).

Modificación

Se presentará una pantalla similar al alta pero con aquellas funcionalidades elegidas preseleccionadas. El usuario deberá elegir las funcionalidades que quedarán para ese perfil, y acto seguido se procederá a modificar la tabla Perfil_Funcionalidad modificando, eliminando y agregando registros de pares nombre_grupo / fid_funcionalidad según se hayan seleccionado en el caso anterior.

Baja

Se presentarán una lista de perfiles (exceptuando los perfiles por default que se describieron secciones atrás). El usuario seleccionará un perfil y se le advertirá que se está por eliminar el mismo. Una vez realizado esto, y confirmado por el usuario, se procederá a hacer un ldap delete del grupo elegido, y se elmininará de la tabla Perfil_Funcionalidad todos los registros donde nombre_grupo sea igual al cn del grupo que se ha eliminado.